Systems and methods for database management of transaction information and authentication data

ABSTRACT

A system for storing data related to a transaction and for authenticating parties involved therewith, the system comprises a database; an application server coupled with the database and configured to store information associated with a plurality of transactions, the information including one or more credentials associated with a plurality of users, a transaction identifier, a source user identifier, a recipient user identifier, and account information related to an recipient account for the recipient user maintained with a financial institution, the application server further configured to receive at least one credential associated with a first user from a first user device and authenticate the first user based on a comparison of the at least one credential against one or more credentials stored at the application server to permit the first user to transmit transaction data related to the transaction and associated with the source user to the financial institution to cause a deposit into the recipient account based on receiving the source user identifier and transaction identifier from the first user device, wherein the first user is not the source user or the recipient user.

RELATED APPLICATIONS INFORMATION

This application claims priority as a Continuation Patent Applicationunder 35 U.S.C. § 120 to U.S. patent application Ser. No. 15/887,790entitled “SYSTEMS AND METHODS FOR DATABASE MANAGEMENT OF TRANSACTIONINFORMATION AND PAYMENT DATA,” filed Feb. 2, 2018, which in turn claimspriority as a Continuation-in-Part Patent Application under 35 U.S.C. §120 to U.S. patent application Ser. No. 14/703,907 entitled “PAYMENTPROCESSING SYSTEM, APPARATUS AND METHOD IN REAL ESTATE TRANSACTIONS,”filed May 5, 2015, which in turn claims priority to Provisional PatentApplication 61/991,555 filed on May 11, 2014 with the same title, all ofwhich are incorporated herein by reference as if set forth in full.

BACKGROUND 1. Technical Field

The embodiments described herein are related to relation management aswell as document management and payment management and verification, inparticular with respect to real-estate or other transactions thatrequire payment handling and verification.

2. Related Art

In certain types of transactions, e.g., real-estate transactions requirethat certain payments be made and verified at certain points in time.Failure to do so can put certain aspects of the transaction or theentire transaction in jeopardy. For example, in a residentialreal-estate transaction, the buyer must provide an earnest money paymentin to confirm the executed Real Estate Purchase and Sale Contract. Thecontract is not enforce until the payment is confirmed.

Typically, the, e.g., earnest money payment is made to the titleinsurance company associated with the transaction or to a separateescrow company. Usually, the buyer must give a check to the buyer'sagent, who must hand deliver, or deliver via Fedex or some othercarrier, the check to the seller's agent, who passes it to the seller,who must then deposit the check.

Moreover, other payments or distributions of funds, whether prior toclosing, at closing, or post-closing, can require checks to be receivedor sent by the title company, which means an employee of the titlecompany is then tasked with making sure that all the checks received areassociated with and credited to the correct accounts, or sent to theproper parties. But sometimes the checks or payments are lost, orassociated with the wrong account, or can be subject fraud.

Wiring funds is also subject to problems because of the risk of unlawfulaccess to e-mails from title company representative to the Buyer and/orthe Buyer Agent containing wiring instructions for wiring of cashamounts.

Accordingly, the process for receiving an verifying such payments ordistributions is often a time consuming, manual process that is stillsubject to mistakes or fraud.

In general, real-estate transactions often involve multiple payments toparties to the transaction, their agents as well as third parties andinclude earnest money, option money (optionally), Buyer's Cash Due atClosing (amount due communicated to Buyer and Buyer Agent via TitleCompany Representative), real property appraisal, real propertyinspection, Homeowners Association Resale Certificate, repair on realproperty made by Seller, commissions due to buyer agent, buyer broker,seller agent and seller broker. Known methods for handling the paymentsconcomitant to real estate purchase and sale transactions and closing ofsuch transactions, which include forwarding/handling of paper checks ande-mailing of wire instructions, are prone to human error, transactionfees, delay and even fraud. The known risks in handling of paymentsinclude inefficiencies in handling of paper checks and inefficiencies incommunications among parties to the transaction, their brokers and thetitle company.

Attempts to convert to electronic systems that allow participants tosend and receive funds electronically also have problems that includesecurity and the ability to verify the identity of a participant.

SUMMARY

Systems and methods for database management of transaction andauthentication data are disclosed herein.

According to one aspect, a system for storing data related to atransaction and for authenticating parties involved therewith, thesystem comprises a database; an application server coupled with thedatabase and configured to store information associated with a pluralityof transactions, the information including one or more credentialsassociated with a plurality of users, a transaction identifier, a sourceuser identifier, a recipient user identifier, and account informationrelated to an recipient account for the recipient user maintained with afinancial institution, the application server further configured toreceive at least one credential associated with a first user from afirst user device and authenticate the first user based on a comparisonof the at least one credential against one or more credentials stored atthe application server to permit the first user to transmit transactiondata related to the transaction and associated with the source user tothe financial institution to cause a deposit into the recipient accountbased on receiving the source user identifier and transaction identifierfrom the first user device, wherein the first user is not the sourceuser or the recipient user.

These and other features, aspects, and embodiments are described belowin the section entitled “Detailed Description.”

BRIEF DESCRIPTION OF THE DRAWINGS

Features, aspects, and embodiments are described in conjunction with theattached drawings, in which:

FIG. 1 is a diagram illustrating an example transaction processingsystem configured in accordance with one example embodiment;

FIG. 2a-j are screen shots illustrating an example process forfacilitating an earnest money payment using the system of FIG. 1;

FIG. 3 is a diagram illustrating how the system of FIG. 1 can carry outthe process illustrated by the screen shots of FIG. 2 in accordance withone example embodiment;

FIG. 4 is a flow chart illustrating an example process for processingoption checks within the system of FIG. 1;

FIG. 5 is a block diagram illustrating certain components of anapplication processor included in the system of FIG. 1 in accordancewith one embodiment;

FIG. 6a-f are screen shots illustrating an example process fordownloading an application, registering a user and establish therelevant credentials to be used for authentication within the system ofFIG. 1;

FIG. 7 is a flow chart illustrating a process for entering a contractwithin the system of FIG. 1;

FIG. 8 is a diagram illustrating the transfer of information and fundsin a large scale sales environment within the system of FIG. 1;

FIG. 9 is a diagram illustrating the interfacing of multiple thirdparties via the application of FIGS. 6a-f within the system of FIG. 1;

FIG. 10 is a diagram illustrating an example process for ordering anappraisal and paying the appraiser within the system of FIG. 1;

FIG. 11 is a diagram further illustrating the application server ofFIGS. 5; and

FIG. 12 is a block diagram illustrating an example wired or wirelesssystem that can be used within the system of FIG. 1.

DETAILED DESCRIPTION

Certain embodiments of a transaction management system that allowsvarious parties to communicate with each other, provide documentationand other information, as well as transmit and verify payment in asecure fashion are disclosed herein. It will be understood that whilevarious steps, components, parties, etc., are disclosed in thedescription of the embodiments below, the embodiments are by way ofexample and should not be seen as limiting the systems and methodsdescribed to only those steps, components, parties, etc., disclosed.

FIG. 1 is a diagram illustrating an example transaction processingsystem 100 configured in accordance with one example embodiment. At thecore of system 100 is application server 120. Application server can beconfigured to manage the transaction as described herein. Applicationserver 120 can also be configured to download a mobile application todevices 110 of various participants in the transaction. Alternatively,the mobile application can be downloaded from an online app -store.Information, documents, checks, etc., can then be captured using devices110 and the mobile application downloaded thereon. The information,documents, checks, etc., can then be processed, verified, etc., onserver 120 and then various information, notices, etc., can be forwardedto various participants or entities as described below.

The various participants can include the buyer agent 100, seller agent140, title company representative 150, lender company representative155, possibly an escrow agent, and various other third parties 157 suchas the appraiser, inspection agent, handyman or repair man, etc. Each ofthese participants can access server 120 via a device 110, such as asmartphone, tablet, laptop or other computer, etc.

Server 120 can also be interfaced on the back-end with the variousinstitutions systems involved with the transactions. Often theseinstitutions are associated with the various participants describedabove. For example, server 120 can be interfaced with the title company180 (and escrow company (not shown) if a separate escrow company isused) and lender 182 as well as the financial intuitions associatedtherewith. Thus, for example, server 120 can be interfaced with thefinancial institution 170 associated with the title company 180 and thefinancial institution(s) 190 associated with the various third parties.In certain embodiments, depending on what payment options are availableserver 120 can also interface with payment service providers 160associated with the various payment options and/or institutions.Alternatively, server 120 can act as the payment processor.

At a high level, each participant can download and register with themobile application. During registration, each participant can create acredential that can be used to authenticate the participant'sinteractions with the mobile application. Once registered, thetransaction can be set up within the system 100. For example, theproperty number can be used to create a “file” within the system. Inaddition, certain information related to each of the participants can beassociated with the file as well as any institution specificinformation, such as the lender's file number, title company's filenumber, etc.

Third party vendors can also sign up and provide the information neededprovide verification of task performance and receive payments as aVendor, such as an inspector, attorney or realtor.

Once the file is set up, the application can be used to exchangeinformation, notices, documentation, payment, etc. In particular, thesystem can be used to make and verify payments such as the earnest moneypayment. While the systems and methods described herein can facilitatepayments via credit card or through service such as Venmo or Paypal,payment via mobile deposit of a Check 21 image or ACH can also besupported. Peer-to-peer payment can also be facilitated as described inmore detail below.

Both mobile deposit and ACH require physical check processing via themobile application. For example, the process for facilitating an earnestmoney payment is illustrated with the aid of the screen shots of FIGS.2a-j and the block diagram of FIG. 3. As can be seen in FIG. 2b , thebuyer's agent can select a payment in the application user interface200. The agent can then select “send earnest money” through the UserInterface (UI) 200 of the buyer's agent 110. As illustrated in FIG. 2c ,the buyer's agent can then select an escrow/title company, via UI 200.For example, the application can be set up to use geolocationcapabilities to poll the escrow agents within a defined radius withrespect to the mobile user.

In certain embodiments, the agent can then select the branch office asillustrated in FIG. 2d . The application can be configured to presentoptions 202 for sorting the branches. As illustrated in FIG. 2e , thebuyer's agent can then be presented with a screen via UI 200 that allowsthe agent to upload the contract, which may already been scanned orotherwise saved in digital form, other information related to ethproperty, realtor, seller and the payment can also be provided.

As can be seen in FIG. 2f , the mobile application 302 can then promptthe buyer's agent to capture an image of the front of the check andpossibly the back as well. FIGS. 2g and 2h illustrate the capturing ofthe front and back of the check. It should also be noted that thiscapture can also be performed by the Title Company at closing, or by anotary as described below for a remote closing.

As illustrated in FIG. 3, the mobile application 302 on the buyer'sagent's device 110 can then cause a check 21 complaint image of thecheck to be provided to the financial institution 170 associated withthe escrow/title company 180 for deposit into the appropriate escrowaccount 172. If mobile deposit is not available, the application 302 canobtain the MICR information from the check information and use it toperform an ACH transaction. As noted above, a payment processor 160 canfacilitate the transaction.

The agent can then receive a confirmation as illustrated in FIG. 2i andan indication that all parties will be notified as illustrate din FIG.2j . As can also be seen in FIG. 3, e.g., email notifications 304 canautomatically be sent to all or selected transaction participants.

Thus, the application 302 or application server 120 can cause anotification to be sent to the escrow/title company 170 associated withthe escrow account 172. The notification can include: the name of thereal estate agent who initiated the transaction; the agent's contactinformation; the property address associated with the transaction; thepayment amount, the name of the seller; the name of the buyer; the nameof the escrow and/or title company; and the date and time of thedelivery of the check.

Optionally, the notification can include a check image. In addition, oralternatively, the notification include a link that can be used toaccess an image of the check through application 302/server 120. Thereceipt notification can be printed along with the check image andplaced in a physical file. Alternatively, a virtual file can bemaintained on server 120 and accessed through application 302 or via aportal to server 120.

In so-called ‘broker escrow states,’ the Broker Escrow Account (asopposed to the Title Company Escrow Account) is designated for receivingescrow payments per the disclosed system. When the real estate sale andpurchase contract is executed in the broker escrow states, the disclosedsystem allows for independent title companies to be involved in thetransaction as follows: (1) The independent Title Company Representativereceives the Real Estate Sale and Purchase Contract that the Buyer orBuyer Agent uploads via the disclosed application and (2) Remote depositcapture of the Buyer's escrow payment is processed per the describedmethod and is deposited in the Broker Escrow Account and the ApplicationServer automatically sends an e-mail confirmation of that payment to theindependent Title Company Representative.

The process for processing option checks can be slightly different andis illustrated in the flow chart of FIG. 4. In this case, the checkimage can be captured by the buyer in step 402 and ACH information canbe pulled from the check image in step 404. In step 406, consent to sendthe ACH transaction information can be obtained from the borrower, i.e.,buyer, via the buyer's application 302. In step 408, the seller emailand the property address can be confirmed and the information sent toserver 120 in step 410.

In step 412, server 120 can then communicate with the seller to confirmthat the seller is willing to receive the option payment. If so, then instep 414, the seller can be requested to provide the property address toverify the seller identity. The seller can then provide the seller'saccount and routing information.

In step 416, server 120 can route the instructions and information tothe appropriate financial institution 170 in order to complete the ACHtransaction. In this case, the Seller provides and electronicendorsement that is payable to the operator of server 120, or can electthe operator to serve as the agent of Seller to receive the funds.

A few things to note about the payment transaction described withrespect to FIGS. 2 and 3. First, as noted in more detail below, thetransaction information does not need to be stored anywhere in thesystem. Thus, wiring instructions are not emailed “in the open” invitinginterception by fraudsters. And obviously, the physical check does notneed to go through several handoffs.

Second, the system can be configured to allow the identity of theparticipants to be authenticated. As noted above, each participant canbe required to create a credential during registration that can be usedor authentication. For example, when a participant is registering, theycan create a PIN, or register a biometric, such as finger print, voice,or face, or some combination thereof as the credential to be used forauthentication. Thus, when the check is transmitted, the, e.g., buyer'sagent can be required to authenticate themselves using their credential.

This can be important, because as noted above, the buyer's agent is notdepositing the check into their own account, rather they are depositingthe check into the escrow account associated with the transaction.Accordingly, extra authentication may be required.

FIG. 5 is a block diagram illustrating certain components of system 100.As can be seen, the system can comprise a number of application/portals504-512 configured to interface with a number of resources 518-522 viaone or more API's 516. The applications/portals can comprise an agentportal 504 as well as a broker portal 506; title company manager portal508 as well as a title company clerk portal 510; and an administerportal 512. In addition, the resources 518-522 can be accessed throughthe application 302 and possibly via a website 502 associated withserver 120.

The resources can include a database for storing and accessingdocuments, information, notifications, check images, etc., associatedwith the sales transaction being handled in the system; anauthentication module 520 for handling the authentication describedabove; and payment processing module for, e.g., interfacing with paymentprocessor 160.

It should be noted that depending on the embodiment, some or all of theportal functionality, API's, and even some of the resources, such as theauthentication and payment processing modules 520 and 522, respectively,can be integrated into mobile application 302.

Each participant must download the application 302, register andestablish the relevant credentials to be used for authentication. Thisprocess can be illustrated with the aid of the screen shots of FIG. 6a-f. In FIG. 6A, it can be seen that once the application 302 is downloadedonto a device 110, the UI 200 can present a registration page. Once theparticipant selects the registration process then, as illustrated inFIG. 6B they can then select what type of participant they want toregister as. Once the participant makes a selection, the application 302can attempt to use location services included in device 110 to, e.g.,aid authentication.

As illustrated in FIG. 6C, the participant can then be prompted throughUI 200 to provide identifying and contact information, and be promptedto validate the participant's device 110. The application prompts theusers to provide identifying, authenticating information such as firstname, last name, e-mail address, mobile telephone number, (for agentsand brokers) real estate license number and the state that is thelicensing authority and driver license number. Users such as the BuyerAgent, Buyer Broker, Seller Agent and Seller Broker may also be promptedto provide their respective bank account identifying information.

Once the select to confirm the device 110, a code can sent to the mobiledevice 110, which the user can then enter for validation as illustratedin the screen shot of FIG. 6D.

As illustrated in the screen shot of FIG. 6E, the participant can atthis point be prompted to generate a credential, which can be as simpleas a PIN. In certain other embodiments, however the credential cancomprise the capturing of one or more biometric through device 110, aswell as other information such as an image of a driver's license, orother identification.

Once registration is complete, the UI 200 can present a home screen fromwhich the participant can access various functions as illustrated in thescreen shot of FIG. 6F. The process flow presented to the participantfor each function presented will vary depending on the type ofparticipant. In other embodiments, only the seller's agent downloadsapplication 302 and other participants interact with server 120 vianotifications and the portals of FIG. 5. In still other embodiments,certain front-end users interface with the system via mobile application302, while certain back-end users use portals.

Subscribing front-end users (Buyer, Buyer Agent, Buyer Broker, Seller,Seller Agent (also known as Listing Agent), Seller Broker) can set upsecure user accounts to access features and functionalities of thedisclosed application as described above. The back-end users of thedisclosed application include the Title Company (and specifiedbranches), Title Company Representative(s), Title Company ProcessingSoftware, Title Company Escrow Agent, Title Company Bank, Buyer's Lender(if financing is involved), Underwriter, Third Party Vendors/ServiceProviders (see below) and Sales Agent of Developer (when Seller in therelevant Real Estate Purchase and Sale Contract is a builder/developer).Back-end users can be authenticated and “pre-boarded” during anintegration process.

In pre-boarding, the provider/host of the disclosed system inputsidentifying information of authorized back-end users of the disclosedsystem, e.g., via admin portal 512. Pre-boarding also includes inputtingidentifying information relating to third party vendors involved in thereal estate purchase and sale transaction and can also include inputtingso-called velocity controls for disbursements to the third party vendorsin which maximum allowed disbursement amounts are specified for eachsuch third party vendor entity receiving a disbursement (payment), e.g.,at/post closing.

The term third party vendor is herein construed broadly and refers toservice providers and taxing authorities involved in real estate salestransactions and includes but is not limited to inspectors, handymen,fumigators, law firms/legal representatives of the parties to thetransaction, the title company, tax assessor entities, underwriters andHomeowner's Warranty Insurance providers. An approval process can berequired for a third party vendor that has not been pre-boarded.

Pre-boarding is required if the Third Party Vendor is to be paid via thedisbursements functionality of the disclosed application. In strictliability states underwriters handle escrow thus taking away fromindependent title companies. Thus, per the disclosed system,underwriters may be pre-boarded thus preserving a role for theindependent title company representative.

To open an order, or initiate the handling of a sales transaction,within system 100, the seller's agent can select documents from the homepage illustrated in FIG. 6F. The seller's agent can then be prompted perUI 200 to scan and upload the executed Real Estate Purchase and SaleContract thus causing the capture of certain metadata in that Contractand the efficient, automatic opening of an order in the Title CompanyProcessing Software.

Title Company Processing Software refers to known software applicationsused by title companies and their representatives and escrow agents to‘open an order,’ initiating a process for effecting a closing of a realestate purchase and sale transaction and then processing the order(including calculating Cash Due at Closing and generating a ClosingDisclosure document). This step helps to enhance efficiencies inhandling of closings by Title Company Representatives and/or TitleCompany Escrow Agents.

The contract can be captured using device 110 and application 302 or itcan be scanned separately and uploaded/downloaded to device 110 orserver 120 where it can be accessed via application 302.

FIG. 7 is a flow chart illustrating a process for entering a contractusing system 100. As noted above, in step 702, the contract can be scanand captured. Certain meta data can be captured at the same time. Forexample, the instructions can cause the server 120 to recognize certainfields in the contract and capture the information included therein. Thecaptured metadata preferably include the names of the parties to thecontract, namely the Buyer and the Seller, sales price, the address forthe real property, the amount of the escrow payment, and indicationwhether or not the buyer seeks financing.

Computer-executable instructions on the Application Server 120 can thencause the transmittal of the Real Estate Purchase and Sale Contract to apre-boarded Title Company and the Title Company Processing System instep 704. Similarly, when the Seller in a Real Estate Purchase and SaleTransaction is a Developer, the Real Estate Sales Contract between theBuyer and the Developer can be communicated to the Title ProcessingSystem and the relevant metadata are automatically captured.

If the Real Estate Purchase and Sale Contract involves financing (asevidenced by captured metadata relating to the financing term/clause inthe Contract), then the Application Server can, in step 706 prompt theBuyer to optionally opt into authorizing the Lender to send a copy ofthe Closing Disclosure (CD) to the Buyer's Agent. This is a usefulautomated notification feature of the disclosed system as it enables theBuyer Agent to actively follow progress of the financing process toensure that closing can take place as planned and that the Buyerprovides the Lender all of the required information as required per theCD under the newly promulgated rules of the Consumer FinancialProtection Board. The opt in by the Buyer protects both the Buyer andthe Buyer Agent and ensures protection of the Buyer's personalidentifiable information found in the CD.

The Application Server 120 comprises computer-executable instructionsfor prompting the Seller Agent, Seller Broker, and if applicable BuyerAgent or Buyer Broker, to upload a scanned copy of each page of theCommission Disbursement Agreement (CDA), in step 708 and once uploaded,the Application Server can be configured to automatically e-mail the CDAto the Title Company Representative for use by the Title CompanyRepresentative in preparation of the Closing Statement and ClosingDocuments in step 710.

Per step 712, the Application Server further comprisescomputer-executable instructions that cause a prompting message to theBuyer to optionally opt in for converting the Buyer's physical checkrepresenting Buyer's Cash Due at Closing to a wire. If the Buyer optsin, then at step 714 the Application Server performs the Convert Checkto Wire functionality after the Buyer captures an image of the front andback of the check and uploads the image to the Application Server.

It is worth noting that by using the system to perform the wiringfunction, the process of emailing instructions in the open can beavoided.

As noted above, certain third parties can also be pre-boarded in orderto facilitate completion of the transaction. For example, the appraiserand home inspector can be pre-boarded. When their services are needed,application 302 or server 120 can be configured to message the thirdparty(ies) in step 716. Once their tasks are complete, such parties canindicate such through the application 302 or a portal on server 120 instep 718. Such a third party may be required to upload confirmation ordocumentation that they have completed their task.

For example, the inspector can scan and upload the inspection report,and appraiser can upload the appraisal. This can cause the propernotifications to the proper participants in step 720.

If any repairs need to be made, then a repairman can be notified andonce the repairs are made the repairman can upload receipts formaterial, etc. Alternatively, the seller can upload receipts to confirmthat he has ensured the repairs.

As noted, the system can be configured such that payment is made tothese third parties once they have confirmed completion of their task.This can involve sending a notification to the participant, such as thebuyer or seller or their agent(s) notifying them that payment is due.Payment can then be handled as described above for, e.g., the optionpayment. Alternatively, payment can be handled at closing as describedbelow.

In step 722, on a date that is before the date of closing set as per theReal Estate Contract (or date of closing as modified and approved by theParties to the transaction and the Title Company Escrow Agent), theApplication Server can be configured to send an automated e-mailnotification to the Buyer and the Buyer Agent of the Cash Due At Closingamount.

For certain transactions, such as transactions involving sale ofcondominium units, there is a provision for transmittal of Homeowners'Association Resale Certificate, which contains important, relevantinformation sought by the buyer. Typically, the Homeowners' Associationassessed a fee to create the HOA Resale Certificate signaling approvalof a change in ownership of a unit. Thus the Application Server 120 canbe configured to prompt the Seller or Seller Agent to upload theHomeowners' Association Resale Certificate (if applicable in thetransaction), in step 724 and once uploaded, the Application Server canbe configured to automatically send an e-mail notification to the Buyer,Buyer Agent, Seller, the Seller Agent and the Title CompanyRepresentative in step 726.

As noted above, the seller can be a developer or builder. Thus, the“seller” will be involved in tens or even hundreds of transactions. Thesystems and methods described herein can clearly make managing suchlarge volumes of transactions much easier. Stated another way, system100 provides the scalability to handle large volumes of transactions.This is illustrated in FIG. 8, which is a diagram illustrating thetransfer of information and funds in a large scale sales environment.

As can be seen, the builder 802 will have the builders back end systems803 that handles all of the data for the various properties. This backend system 803 can communicate with the mortgage company's, orcompanies' 804 Lender Operating System(s) (LOS) 805 and the TitleCompany's 806 Title Operating System (TOS) 807, which can also be incommunication with each other all through or assisted by the application302 and server 120 as well as API's therewith.

Thus, as builder 802 engages in sales process 810 with multiple buyers,system 100 can be facilitating those transaction as described above. Theproperty information and associated documentation can be communicated tomortgage company or lender 804 as can buyer information for buyersinvolved in sales processes 810. Data and documentation for the varioustransactions can be communicated from the lender 804 to the titlecompany 806. As needed, data and documentation can also be transferredbetween title company 806 and lender 802 as can the collection of anddistribution of any funds, such as earnest money or funds to cover,e.g., the appraisal as described above.

System 100 can also be used to handle the closing process 812, which canproceed as described above for the various properties and transactions.

As noted in FIG. 8, the Title Company can handled the closing process812. Thus, if the Title Company has opted into a service called thePost-Closing Payments Disbursement System Functionality, at the time ofclosing, the Application Server 120 can be configured to cause thecomputer-implemented execution of disbursement of payments due to alldisbursees (including but not limited to the Seller (that is if theSeller has opted into receiving funds via the disclosed Closing PaymentsDisbursement functionality of the Application Server), Seller Agent,Seller Broker, Buyer Agent, Buyer Broker, Title Company, legalrepresentative(s), taxing authority/authorities) per the ClosingStatement. The Closing Statement, prepared by the Title CompanyRepresentative or Title Company Escrow Agent via TOS 807, itemizes allof the amounts due to each disbursee and identifies each disbursee.

Payment options in real estate transactions include ACH or wire. Lawsbar the use of ACH payments to escrow accounts and so payments to escrowaccounts are typically made by wire and not ACH. In a conventionalprocess for disbursements of checks at or post-closing, a title companyrepresentative (typically the Escrow Agent) creates physical checks dueto each of the myriad parties, ensures the checks are signed and thechecks are then mailed. Errors may be introduced at each step. System100 provides a more efficient and secure process with the added benefitof converting the checks to wire. Additionally, conventional processesfor effecting disbursements of checks after a closing has the potentialto introduce human error (incorrect amount, incorrect disburse, lack ofauthorized signor(s)), fraud (wrong amount, incorrect disbursee, lack ofauthorized signors) and/or delay in processing (generating, mailing) thechecks.

The disclosed Closing Payments Disbursement Module functionality 812addresses each of these concerns by automating the creation of thedisbursement checks, reducing the amount of dormant money, and byincorporating controls such as the requirement for two signors and theverification of the amounts of the checks against pre-set so-called‘velocity controls’ for limits on the amounts payable to each specifieddisbursee. An added advantage is that the disbursement checks generatedvia the Application Server are ACH. The Application Server generates(prints') electronic checks for each disbursee and in amounts asspecified per the Closing Statement. In creating the electronic checks,no less than two (2) electronic signatures are required to be affixed tothe electronic checks. After the electronic signatures are applied, thechecks are converted to ACH and this is lawful as the check creationoccurs outside of the escrow account. The electronic checks are thenautomatically deposited using the third party payment processing serviceprovider and the Application Server 120 causes the sending of automatede-mail notifications confirming the disbursements.

Controls in the Closing Payments Disbursement System include thefollowing: 1) Electronic signatures of two authorized individualse-signing the checks are required and 2) pre-set velocity controlverification step is applied for each check at the time that theelectronic disbursements are generated. If an amount shown on theClosing Statement for any disburse does not meet the pre-set velocitycontrols for that disbursee, the Application Server 120 will not createthe disbursement order and the Application Server 120 will not generatethat disbursement check and the Application Server 120 sends an e-mailnotification. This step protects against human error and fraud that mayoccur in the disbursement process after closing.

In certain embodiments, there is included a mobile-enabled application302 that connects subscribing users that are licensed real estate agentsand their brokers based on the content they post via the application 302via their user devices. So, for example, an agent may post content(freeform text, photos, zip code, etc.) describing attributes of a realproperty sought by his/her client, such as for example zip code(s).Based on the desired zip code(s) for that real property, the applicationpushes (sends) the content to application users that are licensed realestate agents and brokers in the zip code(s) and/or agents and brokerswho ‘farm’ the specified zip code(s) and/or have listings in the zipcode(s). Today, agents and brokers utilize e-mail, face-to-face meetingsand known social media platforms such as Facebook to communicate withtheir contacts (friends') regarding real estate-related business. Thiscapability offers a more efficient, secure alternative for agents andbrokers to communicate real estate-related business with automaticallytargeted communications while preserving a professional image that isseparate from the agents and brokers' non-business-related postings onsocial media.

Thus, as illustrated in FIG. 9, multiple third parties 157 can also beinterfaced with system 100 via an application 302. These third partiescan be provide services, documentation, engage in “chat” communications,etc. Some of these third parties may provide or receive funds eitherduring the transaction or at closing as described above.

System 100 can greatly increase the efficiency of dealing with suchthird parties and can increase the efficiency with which such partiesare paid and provide better records of the services provided by suchthird parties and any reports provided thereby.

The potential complexity of these processes, but the efficiency providedby system 100 is illustrated with respect to the diagram of FIG. 10,which illustrates the process for ordering an appraisal and paying theappraiser using system 100. First, lender 804 requests, via the LOS 805that the borrower or buyer pay for the appraisal (1 b in FIG. 10). Thelender 804 also notifies server 120 that the buyer was notified to pay(1 b).

If not done already, buyer can then download application 302 from aplatform 1002 such as Google Play or iTunes and can register with server120 as described above (2). The platform 1002 can ping server 120 (3)and server 120 can send information related to payment in response (4).

Buyer can then capture an image of a check and can forward to server 12095). Server 120 can then confirm to the lender that payment was received(6 a) and confirm receipt to the buyer (6 b). The Lender's LOS 805 canthen order the appraisal from Appraiser 157 (7) and once the appraiserhas completed the appraisal, then he or she can cause the appraisal andthe invoice to be sent to the LOS 805 (8).

LOS 805 can then send the invoice to server 120 (9) and server 120 canreconcile the invoice to the amount paid and request more funds ifneeded (10). Once the appropriate funds are received, then server 120can pay appraiser 157 via dedicated FTP to their financial institution170 (11). Server 120 can then send a notification of a Paid Outside ofClosing (POC) transaction to all parties including the title company 806(12).

Thus, multiple parties and third parties can use system 120 to accessvarious services. As illustrated in FIG. 5, a party or user can sign(and register if needed) to the platform hosted by server 120 via anapplication 302, e.g., downloaded form a platform 1002. Once signed in,this will take the user to their landing page, which can give themaccess to the various resources 518-518-530, e.g., via portals 504-512.

FIG. 11 is another way to look at the resources provided by the platformhosted on server 120. FIG. 11 is a cross matrix of the various usertypes and the services provided.

The Authentication piece can be very powerful. As noted above, when auser registers they can be required to create a credential forauthentication purposes. In certain embodiments, this can comprise asimple PIN. Bu tin others, the credential can also comprise biometricsand other factors. Moreover, a user can be required to capture an imageof their identification, such as a driver's license or passport.Moreover, geolocation can be used to verify identification or to verifythat a service being provided, such as an inspection, is actually beingperformed at the correct location.

Not only can this increase the level of authentication and preventfraud, some of this information can also be stored for verificationpurposes.

In certain embodiments, a Notary can be used for, e.g., a remoteclosing. In such a process, a Notary can be dispatched to the locationof the Buyer. Using the application, the Notary can authenticate theuser as described above, e.g., by capturing driver's licenseinformation, etc. The location of the Notary can then be verified usingthe geolocation capability of device 110. Video capabilities of device110 can then be used to capture the signing of the documents. In certainembodiments, the actual signed documents can be loaded to server 120through the application. The closing funds can then be captured asdescribed above.

One option for capturing the closing funds, or any other funds that hasnot yet been described is to allow the, e.g., Seller to use their DebitCard. AS noted above, various types of monies are required to be putinto escrow during transactions such as real-estate transactions. WhileACH is a convenient way to transfer funds, Ach will not generally workfor, e.g., real-estate deals, because the payor can reverse thetransaction for up to 90 days. But most, e.g., real-estate closingsoccur within 40 days. Thus, as noted above for, e.g., real-estatetransactions, cashier's checks, paper checks, and wired funds are used;however, paper checks are being used less and less and the process forwiring funds or getting a cashier's check are inconvenient andinefficient. Platform 100 enables the user to capture the debit cardinformation in order to generate an electronic check that can beelectronically signed by the account holder and then sent to the escrowaccount for processing.

In other words, the user provides the debit card information. Server 120contacts the appropriate financial institution 170 to verify funds andprovide the transaction details so that the funds can be transferredfrom the user's account to, e.g., escrow. Once the funds are verifiedand the transfer completed, the financial institution server 120 cangenerate a check image that meets the requirements of, e.g., Check 21that can actually be processed and saved.

FIG. 12 is a block diagram illustrating an example wired or wirelesssystem 550 that may be used in connection with various embodimentsdescribed herein. For example the system 550 may be used as or inconjunction with the system 100, as previously described with respect to1-11. The system 550 can be a conventional personal computer, computerserver, personal digital assistant, smart phone, tablet computer, or anyother processor enabled device that is capable of wired or wireless datacommunication. More particularly, the system 550 may represent theapplication server. Other computer systems and/or architectures may bealso used, as will be clear to those skilled in the art.

The system 550 preferably includes one or more processors, such asprocessor 560. Additional processors may be provided, such as anauxiliary processor to manage input/output, an auxiliary processor toperform floating point mathematical operations, a special-purposemicroprocessor having an architecture suitable for fast execution ofsignal processing algorithms (e.g., digital signal processor), a slaveprocessor subordinate to the main processing system (e.g., back-endprocessor), an additional microprocessor or controller for dual ormultiple processor systems, or a coprocessor. Such auxiliary processorsmay be discrete processors or may be integrated with the processor 560.

In one embodiment, the application server can be configured with morethan one processor in order to separately process the incoming signalsfrom a plurality of sensing devices, while a yet further processor isresponsible for handling communication with the gateway device. Inanother embodiment, the gateway device may also be configured with aplurality of processors, with one processor configured to receive andprocess data from the central control device, a second processorconfigured to generate graphical user interfaces to display the receiveddata to the user on a display of the gateway device and a thirdprocessor to communicate with the remote server. For a portableelectronic device such as the central control device and gateway device,the processors may be low power processors to reduce power consumptionon the devices' batteries.

The processor 560 is preferably connected to a communication bus 555.The communication bus 555 may include a data channel for facilitatinginformation transfer between storage and other peripheral components ofthe system 550. The communication bus 555 further may provide a set ofsignals used for communication with the processor 560, including a databus, address bus, and control bus (not shown). The communication bus 555may comprise any standard or non-standard bus architecture such as, forexample, bus architectures compliant with industry standard architecture(“ISA”), extended industry standard architecture (“EISA”), Micro ChannelArchitecture (“MCA”), peripheral component interconnect (“PCI”) localbus, or standards promulgated by the Institute of Electrical andElectronics Engineers (“IEEE”) including IEEE 488 general-purposeinterface bus (“GPM”), IEEE 696/S-100, and the like. These standards maybe applicable to the remote server, while additional or varyingstandards may apply to portable electronic devices such as the centralcontrol device or sensing devices.

System 550 preferably includes a main memory 565 and may also include asecondary memory 570. The main memory 565 provides storage ofinstructions and data for programs executing on the processor 560. Themain memory 565 is typically semiconductor-based memory such as dynamicrandom access memory (“DRAM”) and/or static random access memory(“SRAM”). Other semiconductor-based memory types include, for example,synchronous dynamic random access memory (“SDRAM”), Rambus dynamicrandom access memory (“RDRAM”), ferroelectric random access memory(“FRAM”), and the like, including read only memory (“ROM”).

The secondary memory 570 may optionally include an internal memory 575and/or a removable medium 580, for example a floppy disk drive, amagnetic tape drive, a compact disc (“CD”) drive, a digital versatiledisc (“DVD”) drive, etc. The removable medium 580 is read from and/orwritten to in a well-known manner. Removable storage medium 580 may be,for example, a floppy disk, magnetic tape, CD, DVD, SD card, etc.

The removable storage medium 580 is a non-transitory computer readablemedium having stored thereon computer executable code (i.e., software)and/or data. The computer software or data stored on the removablestorage medium 580 is read into the system 550 for execution by theprocessor 560.

In alternative embodiments, secondary memory 570 may include othersimilar means for allowing computer programs or other data orinstructions to be loaded into the system 550. Such means may include,for example, an external storage medium 595 and an interface 590.Examples of external storage medium 595 may include an external harddisk drive or an external optical drive, or and external magneto-opticaldrive.

Other examples of secondary memory 570 may include semiconductor-basedmemory such as programmable read-only memory (“PROM”), erasableprogrammable read-only memory (“EPROM”), electrically erasable read-onlymemory (“EEPROM”), or flash memory (block oriented memory similar toEEPROM). Also included are any other removable storage media 580 andcommunication interface 590, which allow software and data to betransferred from an external medium 595 to the system 550.

System 550 may also include an input/output (“I/O”) interface 585. TheI/O interface 585 facilitates input from and output to external devices.For example the I/O interface 585 may receive input from a keyboard ormouse and may provide output to a display. The I/O interface 585 iscapable of facilitating input from and output to various alternativetypes of human interface and machine interface devices alike.

System 550 may also include a communication interface 590. Thecommunication interface 590 allows software and data to be transferredbetween system 550 and external devices (e.g. printers), networks, orinformation sources. For example, computer software or executable codemay be transferred to system 550 from a network server via communicationinterface 590. Examples of communication interface 590 include a modem,a network interface card (“NIC”), a wireless data card, a communicationsport, a PCMCIA slot and card, an infrared interface, and an IEEE 1394fire-wire, just to name a few.

Communication interface 590 preferably implements industry promulgatedprotocol standards, such as Ethernet IEEE 802 standards, Fiber Channel,digital subscriber line (“DSL”), asynchronous digital subscriber line(“ADSL”), frame relay, asynchronous transfer mode (“ATM”), integrateddigital services network (“ISDN”), personal communications services(“PCS”), transmission control protocol/Internet protocol (“TCP/IP”),serial line Internet protocol/point to point protocol (“SLIP/PPP”), andso on, but may also implement customized or non-standard interfaceprotocols as well.

Software and data transferred via communication interface 590 aregenerally in the form of electrical communication signals 605. Thesesignals 605 are preferably provided to communication interface 590 via acommunication channel 600. In one embodiment, the communication channel600 may be a wired or wireless network, or any variety of othercommunication links. Communication channel 600 carries signals 605 andcan be implemented using a variety of wired or wireless communicationmeans including wire or cable, fiber optics, conventional phone line,cellular phone link, wireless data communication link, radio frequency(“RF”) link, or infrared link, just to name a few.

Computer executable code (i.e., computer programs or software) is storedin the main memory 565 and/or the secondary memory 570. Computerprograms can also be received via communication interface 590 and storedin the main memory 565 and/or the secondary memory 570. Such computerprograms, when executed, enable the system 550 to perform the variousfunctions of the present invention as previously described.

In this description, the term “computer readable medium” is used torefer to any non-transitory computer readable storage media used toprovide computer executable code (e.g., software and computer programs)to the system 550. Examples of these media include main memory 565,secondary memory 570 (including internal memory 575, removable medium580, and external storage medium 595), and any peripheral devicecommunicatively coupled with communication interface 590 (including anetwork information server or other network device). Thesenon-transitory computer readable mediums are means for providingexecutable code, programming instructions, and software to the system550.

In an embodiment that is implemented using software, the software may bestored on a computer readable medium and loaded into the system 550 byway of removable medium 580, I/O interface 585, or communicationinterface 590. In such an embodiment, the software is loaded into thesystem 550 in the form of electrical communication signals 605. Thesoftware, when executed by the processor 560, preferably causes theprocessor 560 to perform the inventive features and functions previouslydescribed herein.

The system 550 also includes optional wireless communication componentsthat facilitate wireless communication over a voice and over a datanetwork. The wireless communication components comprise an antennasystem 610, a radio system 615 and a baseband system 620. In the system550, radio frequency (“RF”) signals are transmitted and received overthe air by the antenna system 610 under the management of the radiosystem 615.

In one embodiment, the antenna system 610 may comprise one or moreantennae and one or more multiplexors (not shown) that perform aswitching function to provide the antenna system 610 with transmit andreceive signal paths. In the receive path, received RF signals can becoupled from a multiplexor to a low noise amplifier (not shown) thatamplifies the received RF signal and sends the amplified signal to theradio system 615.

In alternative embodiments, the radio system 615 may comprise one ormore radios that are configured to communicate over various frequencies.In one embodiment, the radio system 615 may combine a demodulator (notshown) and modulator (not shown) in one integrated circuit (“IC”). Thedemodulator and modulator can also be separate components. In theincoming path, the demodulator strips away the RF carrier signal leavinga baseband receive audio signal, which is sent from the radio system 615to the baseband system 620.

If the received signal contains audio information, then baseband system620 decodes the signal and converts it to an analog signal. Then thesignal is amplified and sent to a speaker. The baseband system 620 alsoreceives analog audio signals from a microphone. These analog audiosignals are converted to digital signals and encoded by the basebandsystem 620. The baseband system 620 also codes the digital signals fortransmission and generates a baseband transmit audio signal that isrouted to the modulator portion of the radio system 615. The modulatormixes the baseband transmit audio signal with an RF carrier signalgenerating an RF transmit signal that is routed to the antenna systemand may pass through a power amplifier (not shown). The power amplifieramplifies the RF transmit signal and routes it to the antenna system 610where the signal is switched to the antenna port for transmission.

The baseband system 620 is also communicatively coupled with theprocessor 560. The central processing unit 560 has access to datastorage areas 565 and 570. The central processing unit 560 is preferablyconfigured to execute instructions (i.e., computer programs or software)that can be stored in the memory 565 or the secondary memory 570.Computer programs can also be received from the baseband processor 610and stored in the data storage area 565 or in secondary memory 570, orexecuted upon receipt. Such computer programs, when executed, enable thesystem 550 to perform the various functions of the present invention aspreviously described. For example, data storage areas 565 may includevarious software modules (not shown) that are executable by processor560.

Various embodiments may also be implemented primarily in hardware using,for example, components such as application specific integrated circuits(“ASICs”), or field programmable gate arrays (“FPGAs”). Implementationof a hardware state machine capable of performing the functionsdescribed herein will also be apparent to those skilled in the relevantart. Various embodiments may also be implemented using a combination ofboth hardware and software.

Furthermore, those of skill in the art will appreciate that the variousillustrative logical blocks, modules, circuits, and method stepsdescribed in connection with the above described figures and theembodiments disclosed herein can often be implemented as electronichardware, computer software, or combinations of both. To clearlyillustrate this interchangeability of hardware and software, variousillustrative components, blocks, modules, circuits, and steps have beendescribed above generally in terms of their functionality. Whether suchfunctionality is implemented as hardware or software depends upon theparticular application and design constraints imposed on the overallsystem. Skilled persons can implement the described functionality invarying ways for each particular application, but such implementationdecisions should not be interpreted as causing a departure from thescope of the invention. In addition, the grouping of functions within amodule, block, circuit or step is for ease of description. Specificfunctions or steps can be moved from one module, block or circuit toanother without departing from the invention.

Moreover, the various illustrative logical blocks, modules, and methodsdescribed in connection with the embodiments disclosed herein can beimplemented or performed with a general purpose processor, a digitalsignal processor (“DSP”), an ASIC, FPGA or other programmable logicdevice, discrete gate or transistor logic, discrete hardware components,or any combination thereof designed to perform the functions describedherein. A general-purpose processor can be a microprocessor, but in thealternative, the processor can be any processor, controller,microcontroller, or state machine. A processor can also be implementedas a combination of computing devices, for example, a combination of aDSP and a microprocessor, a plurality of microprocessors, one or moremicroprocessors in conjunction with a DSP core, or any other suchconfiguration.

While certain embodiments have been described above, it will beunderstood that the embodiments described are by way of example only.Accordingly, the systems and methods described herein should not belimited based on the described embodiments. Rather, the systems andmethods described herein should only be limited in light of the claimsthat follow when taken in conjunction with the above description andaccompanying drawings.

What is claimed:
 1. A system for storing data related to a transactionand for authenticating parties involved therewith, the systemcomprising: a database; an application server coupled with the databaseand configured to store information associated with a plurality oftransactions, the information including one or more credentialsassociated with a plurality of users, a transaction identifier, a sourceuser identifier, a recipient user identifier, and account informationrelated to an recipient account for the recipient user maintained with afinancial institution, the application server further configured toreceive at least one credential associated with a first user from afirst user device and authenticate the first user based on a comparisonof the at least one credential against one or more credentials stored atthe application server to permit the first user to transmit transactiondata related to the transaction and associated with the source user tothe financial institution to cause a deposit into the recipient accountbased on receiving the source user identifier and transaction identifierfrom the first user device, wherein the first user is not the sourceuser or the recipient user.
 2. The system of claim 1, wherein theapplication server is configured to authenticate each user of theplurality of user for access to the application server based onreceiving at least one credential from each user and comparing the atleast one credential against the one or more credentials stored at theapplication server and associated with each of the plurality of users.3. The system of claim 1, wherein the one or more credentials comprisesone or more of at least a personal identification number, a biometricidentifier, identifying documentation related to the user, ageolocation, and any combination thereof
 4. The system of claim 3,wherein the biometric identifier comprises one or more of a fingerprint, a voice recording, a facial recognition identifier, rental scan,or any combination thereof.
 5. The system of claim 3, wherein theidentifying documentation comprises one or more of a driver's license, apassport, a picture identification, or any combination thereof.
 6. Thesystem of claim 1, wherein the at least one credential associated withthe first user comprises at least a current geographical location of thefirst user device, and one or more credentials stored at the applicationserver comprises at least a predetermined geographical location, whereinthe application server is configured to authenticate the first userbased on a comparison of the current geographic location against thepredetermined geographical location.
 7. The system of claim 1, whereinthe first user device is a mobile device comprising an applicationrunning thereon, and wherein the application is configured to cause thedevice to capture an image of a check related to payment associated withthe transaction and process the image, wherein transmitting thetransaction data comprises transmitting at least one of the image of thecheck, data from processing the image, or any combination thereof. 8.The system of claim 1, further comprising a mobile device comprising anapplication running thereon, and wherein the application is configuredto cause the device to cause the device to receive the one or morecredentials from a user of the plurality of users and transmit the oneor more credentials to the application server for storage andregistering the user with the application server based on the one ormore credentials
 9. The system of claim 8, wherein the registering theuser comprises receiving an identifier of a type of user at the mobiledevice, causing the user to input authenticating information into themobile device, causing a random code to be sent to the mobile device andentered into the application to validate the user and mobile device, andcausing the mobile device to capture the one or more credentials fromthe user.
 10. The system of claim 1, wherein the application serverincludes portals for each user of the system that allows each user toaccess the application server and manage accounts related thereto. 11.The system of claim 10, further comprising a mobile device associated toat least one user of the plurality of users and an application runningthereon, where the at least one user accesses the application sever viathe application and the remaining users of the plurality of users accessthe application sever through the portals associated therewith.
 12. Thesystem of claim 1, wherein the application server is further configuredto send a notification to a seller, seller agent, or both.
 13. Thesystem of claim 1, wherein the application server further comprises adatabase management resource for managing the database, a paymentprocessing resource for managing payment transactions, and anauthentication resource for managing the authentication of users of theapplication server.